Protocols for reporting power status over multiple buses

ABSTRACT

An automated power reporting system is provided in one aspect. The system includes one or more devices that can report or transmit power status information over a bus or network. A protocol component utilizes a generalized protocol to process or convert the power status information over the network in order to facilitate power management operations for a plurality of devices. In this manner, devices that send power information can interact and exploit personal computing resources in order to better help users manage limited power resources for their respective devices.

BACKGROUND

Over the past few years, more devices are starting to include batteriesor other renewable/rechargeable sources of power. These devices oftenneed to convey their power settings to a host personal computer (PC),but due to the lack of a standardized protocol with the PC, variousindependent hardware vendors (IHVs) choose not to implement thissupport. In general, there are a host of problems in the industry due tolack of consistency in the manner in which to report power. In but a fewexamples, these problems may include:

First, IHVs create random User Interfaces (UI): Due to the lack of auniform or standardized manner to report battery strength for example,various IHVs choose to implement their own software on PCs to displaythis type of information. This level of innovation may be suitable forcompetition between IHVs, but often confuses the end user. Also, IHVscreate software that exists in control panels, in the system tray, forinstance, and often on the computer desktop for their specific hardware.Thus, the user does not have a standard location where they can navigateto see the battery strength of their respective devices, for example.

Secondly, problems include lack of reporting when power is low: Mostlaptops today have smart batteries that can report to the operatingsystem (OS), through standardized calls (e.g., ACPI), the charge left inthe battery. When the battery is running weak, the laptop can send anotification to the user to charge the laptop or turn it off to preventloss of data or productivity; or can choose to take action itself (e.g.,save all data and hibernate to prevent loss in terms of critically lowbattery).

Another problem relates to smart algorithms to prolong battery life:Since most laptops today report battery strength in a standardized wayto the operating system, the OS could potentially have the opportunityto perform smarter tasks to prolong the life of the battery byperforming actions like slowing down the processor, turning down WiFiradios, decreasing screen brightness, and so forth. While this can alsobe performed by the device itself, this operation may be computationallyexpensive and may not have all the information to calculate this asaccurately as the PC. However, since there is no standardized procedureto report a device's charge to an operating system, there is no currentprocess for controlling or prolonging the life of the charge on adevice, for example.

Other problems with current reporting systems, is poor diagnoseability:For instance, when a wireless device stops functioning with the PC it isvery difficult to diagnose the source of the problem. If the user had aprocedure to visit a common area that identified all devices aroundtheir PC and observe the battery strength on the respective devices, forinstance, they may be able to observe the low power status on alldevices (or receive notifications of low power) and thus, replacebatteries in time. There is currently no standardized process to reportan external device's battery power to a PC. Though there are a number ofdifferent values that could potentially be reported through systemtransports, there is currently no standardized mechanism for exploitingsuch values.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

A standardized protocol is provided for devices, manufactured bymultiple vendors, to report charge or power status in an efficient,robust, scalable and generalized manner. Such status can be relayed tocomponents that facilitate power management operations of the devicessuch as a host computing operating system, for example. By employing ageneralized or standardized protocol, different vendors can transportpower information to the host via the protocol while mitigating vendorsoftware development requirements for interfacing to system platforms.They can also choose to provide vendor software for value-adddifferentiation that is pertinent to a specific device and not genericto all devices, if desired. Power management can include a plurality ofapplications that are not presently supported such as cell-phonereporting of power status to a personalized message on a computer,devices reporting to an operating system over multiple system busseswith current power conditions, or exploiting computing capabilities ofthe host to determine available power resources of the device, forexample, thus offloading computing requirements of the device.

In one aspect, devices can receive power from different sources. Thedevices can also extract power from a host system via a cable (e.g., buspowered over USB cable), or obtain power from a wall adapter, or have a(possibly rechargeable) internal battery, wherein the latter twoscenarios are examples of self-powered devices. Industry analysis showsan increasing trend in self-powered devices over both wired buses (e.g.,USB, 1394, IEEE 802.3 and so forth) and wireless buses (e.g., Bluetooth,WiFi, and so forth). A number of these devices provide capabilities tomeasure battery power and power draw, and report this information on thedevice such as having bars indicating battery strength on cell phones,for example. However, the standardized protocol enables such devices toreport this battery power or status, for example, on partnered systemswithout also coding components on the partnered system to exploit suchstatus. In one particular aspect, a Human Interface Device (HID)protocol can be employed as the standardized protocol to transport datareflecting how a device can report its measured battery strength andalso transmit it over the HID protocol, for example. While otherreporting protocols in addition to HID are possible, HID can be usefulas it works across many diverse buses or networks, is scalable (allowsvendors to provide device specific information if desired) and providesaccess to information directly to user mode applications.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram illustrating an automated powerreporting and processing system.

FIG. 2 illustrates exemplary protocol methods that employ device powerstatus data.

FIG. 3 illustrates a flow diagram illustrating a power reportingprocess.

FIG. 4 illustrates example applications for power reporting inaccordance with a standardized protocol.

FIG. 5 illustrates an example protocol that can be employed for powerreporting.

FIG. 6 is an example user interface for power reporting on a host.

FIG. 7 is a schematic block diagram illustrating a suitable operatingenvironment.

FIG. 8 is a schematic block diagram of a sample-computing environment.

DETAILED DESCRIPTION

A generalized power reporting protocol is provided to facilitate powermanagement operations with numerous device applications when operatingwith host computing systems. In one aspect, an automated power reportingsystem is provided. The system includes one or more devices that canreport or transmit power status information over a network or bus. Aprotocol component utilizes a generalized protocol to process or convertthe power status information over the network or bus in order tofacilitate power management operations for a plurality of devices. Inthis manner, devices that send power information (e.g., battery status)can interact and exploit personal computing resources in order to betterhelp users manage limited power resources for their respective devices.The network can include personal computer busses, wireless connections,standard wired connections, and so forth if desired, when reporting thepower status information to the host computing systems.

As used in this application, the terms “component,” “protocol,”“system,” and the like are intended to refer to a computer-relatedentity, either hardware, a combination of hardware and software,software, or software in execution. For example, a component may be, butis not limited to being, a process running on a processor, a processor,an object, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on aserver and the server can be a component. One or more components mayreside within a process and/or thread of execution and a component maybe localized on one computer and/or distributed between two or morecomputers. Also, these components can execute from various computerreadable media having various data structures stored thereon. Thecomponents may communicate via local and/or remote processes such as inaccordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal).

Referring initially to FIG. 1, a system 100 illustrates automated powerreporting and processing for devices. A standardized power protocolcomponent 110 (also referred to as protocol component) relays powerstatus 120 between one or more devices 130 and a system platform or host140 (or hosts). Such status 120 can be transmitted over a network suchas the Internet, a local area network, a wireless network, and/or acrossone or more computer system buses, for example, associated with the host140. The buses could include universal serial buses, wireless buses,parallel buses, and so forth. In general, the standardized protocol 110enables differing vendors of the devices 130 to control power managementin a proprietary manner if desired, yet, still enabling reporting ofdevice power status 120 according to prescribed interfaces of theprotocol component 110. In this manner, third party hosts, platforms,and operating systems 140 can collaborate with the devices 130 toprovide an enhanced user experience for managing power requirements ofthe devices. It is noted that the protocol component 110 can be locatedoutside the host 140 or the devices 130, within one of these respectivecomponents, or have functionality shared between the host and thedevices.

The devices 130 can be substantially any type of system or remote devicesuch as drivers, processors, network cards, system controllers, cellphones, cameras, or substantially any type of device capable ofreporting power status over remote networks or system buses such asbattery strength, percentage of operating time remaining, battery trendsand so forth. For instance, a cell phone could send a warning via theprotocol 110 to the host, where the host sends an electronic message tothe user informing them of the device's current status. In anotherexample, the device 130 could send current battery status to the host140 and have the host perform more complex computing tasks over timesuch as performing complex non-linear battery life remaining analysiswhen power on the device falls below a predetermined threshold. Inanother case, divergent operating system components could report powerstatus to the host 140 in a unified and scalable manner for multipledevices and reported in a convenient, centralized location or interface.Another example can be more simplified where a device 130 merely reportsthat according to its power display, two bars of a full strength fivepower bar setting are remaining on the display. As can be appreciated,various applications can be supported by the protocol component 110 withmore examples described below.

When status data 120 is reported across to the host 140 from the devices130, the following describes some examples how the system 100 can usesuch data and provide a rich user experience. These can include:

Single consolidated user interface (UI) to report the battery strengthof all devices;

The ability for vendors to write complex software to accuratelycalculate battery strength and report remaining battery life as afunction of time (based on current usage activities);

The ability to create a platform for software vendors to createapplications that can read the device's battery strength and performsmart tasks with such status;

The ability to link to consumer or vendor websites to purchase newerbatteries (the type of battery needed can be reported by the device overthis protocol);

The ability to warn users that battery of a device (e.g., a cell phonein their pocket) is running low without the user having to look directlyat the device;

The ability to warn users when their batteries/device are getting weakerover multiple charging cycles, and hence be in need of replacement.Before proceeding, the following definitions are provided:

-   -   Human Interface Devices (HID) is a protocol definition for        sending low bandwidth, tight latency data from various input and        output devices. This protocol was originally specified over the        USB bus, and has been expanded to other buses including        Bluetooth, game port, and so forth. Some of the typical examples        of HID class devices include keyboards, pointing devices, game        controllers, front-panel controls, and so forth.    -   Independent Hardware Vendor (IHV) is an organization that        develops hardware devices (e.g., cell phones, keyboards, mass        storage devices, and so forth) that work with PCs.    -   Independent Software Vendor (ISV) is an organization that        develops software (e.g., word processors, backup utilities, data        synchronization utilities and so forth). ISVs generally produce        applications that do not require a specific make/model of        hardware. Software needed for a specific piece of hardware        originates from the JHV, usually along with the device.    -   A battery reporting device is a device that contains a (possibly        rechargeable) battery and has the capacity of measuring at least        its battery strength and reporting this value to a paired        device.

FIG. 2 illustrates exemplary protocol methods 200 that utilize devicepower status data. In general, a respective device should be able to atleast measure a charge stored in its battery (or other form of renewablepower source) and report it to a personal computer or other host overone of the following standardized methods 200. At 210, a first method orprocess standardizes on certain basic and extended HID Usages, forexample. A Human Interface Device (HID) protocol provides many usages(tags that identify what the power or parameter value generally shouldmean) to report power. A service for receiving power status can beprovided or it can be read directly from a control panel, to listen toHID messages as they are generated by the device to report batterystrength. In some cases (e.g., when the control panel or server isstarted) the operating system may request for current battery status ascompared to waiting on the device for the next battery update. HID isavailable on various buses ranging from USB, Bluetooth, serial toWireless USB, for example. It is also possible to run HID over 1394 andIP buses, for example. The cost of an HID endpoint (for USB—as it doesnot need an interrupt interface on USB) or profile (for Bluetooth, viaSDP records) is low. Also, IHVs do not generally need to write anysoftware i.e., their hardware will work out of the box and reportbattery strength, communicating with a standardized piece of softwaredeveloped or distributed by a software vendor.

At 220, a second method creates an application interface or library fromwhich to interact with the host. This can include creating aninfrastructure (e.g., Windows Management Infrastructure) for any driverto report Battery strength. The operating system may instead choose toimplement extensions for device drivers to report battery strength. Thedevice driver does not have to be tied to any particular bus and canalso function for network connected devices. This process 220 for IHVscan make existing hardware compliant with the new initiatives by writingsoftware drivers to report battery strength. The driver can be in kernelor in user mode, for example, whereby the driver can work around defectsin hardware or perform complex calibration of battery reporting beforeproviding the charge value to the operating system.

At 230, the operating system can standardize user interfaces to reportgeneric battery strength values (similar to the cell phone signal bars)instead of battery strength as a percentage to reduce the hit of IHVsproducing lower-cost devices that can not afford to have complex batterystrength readers. However an extended battery indication scheme can beemployed to show more accurate battery strength indicators whenimplemented by IHVs. The operating system may also provide sliders toallow for users to receive notifications when the battery strength dipsbelow a user-specified value, indicating to the user that their deviceneeds new batteries. The operating system may also store when the lasttime the user updated batteries on the device (or recharged batteries)to identify life of battery if needed. In another aspect, the operatingsystem can be provided with functionality to profile devices over timeto retrieve a more accurate battery life to usage time mapping, forexample. Since battery performance changes over time, identifying thesetrends can be enhanced by software. Also, usage patterns vary, andbattery life is dependent on usage. A personal computer can track thisinformation as well to help determine amount of battery time left.

FIG. 3 illustrates an example power reporting process 300. While, forpurposes of simplicity of explanation, the methodology is shown anddescribed as a series or number of acts, it is to be understood andappreciated that the subject process is not limited by the order ofacts, as some acts may, in accordance with the subject process, occur indifferent orders and/or concurrently with other acts from that shown anddescribed herein. For example, those skilled in the art will understandand appreciate that a methodology could alternatively be represented asa series of interrelated states or events, such as in a state diagram.Moreover, not all illustrated acts may be required to implement amethodology in accordance with the subject process.

Proceeding to 310, a decision is made as to whether a device measuresbattery charge. If not, the process proceeds to 320, and hides a batteryreporting user interface since no battery reporting capabilities areavailable, where the process then ends at 330. If the device can measurecharge at 310, the process proceeds to 340 and determines whether or nota device reports battery charge in accordance with the standardizedreporting protocol described above. If such reporting capabilities areavailable at 340, the process proceeds to 350 and reads the rate atwhich the device reports battery charge. The charge is then displayed ina control panel like display at 360 or other type user interface. If thedevice does not report battery charge at 340, the process proceeds to370 to determine whether a hardware vendor has installed software tomimic compliance with standard reporting protocols. If so, the processproceeds to 350 and executes as described above. If not, the processproceeds to 380 and greys out, partially hides, or hides a batteryreporting user interface before ending at 330.

Referring to FIG. 4, example protocol reporting applications 400 areillustrated. At 410, a Bluetooth keyboard to PC application is shown.For instance, a user purchases a new Bluetooth keyboard and brings ithome. They insert batteries into the device, and follow the instructionsto associate the device. Later, the user then receives an indicator thathis batteries are low and needs to replace them soon. This warningallows the user to track battery strength rather than waiting until thelast minute when the batteries fail and the device stops functioningwithout any indication to the end customer as to what went wrong.

At 420, a cell phone application is shown where a cell phone isconnected to a personal computer via a USB connection. Here, the userattaches a USB cell phone to the PC to use it as a modem for internetconnectivity. Then the user installs the software for the cell phonefrom a vendor website. This software causes the cell phone to reportfiner granularity of battery status. As the device is being charged, thevendor provided application shows the current strength of the battery,its charging rate and an indication (in terms of time) when the devicewill be fully charged/discharged at its current rate of usage.

At 430, centralized reporting of status for multiple devices is shown.In this case, the user has multiple self-powered devices connected tothe PC that can each report their battery strength. They open thecomputer control panel, select the device viewer and observe all thehardware devices attached to the PC. Thus, in a single environment, theuser sees all devices attached to their PC and also sees the batterystrength reported by all devices in a unified user interface.

At 440, a cell phone application is shown. For instance, the user has aBluetooth cell phone and the cell phone's battery usually lasts for 2days (normal use). They charged their phone the morning before but itstill has some charge left (i.e., the device is currently not reporting“critically low” battery status). Assume that the PC and the cell phoneare already associated over Bluetooth. Since the PC knows the user'supcoming schedule for the day and knows that they will be traveling andattending a 4-6 pm conference call via cell phone from the road, theuser receives a reminder in the afternoon to charge the phone (to lastthrough the conference call). If there was no integration with acalendar service, for example, the user would not have received awarning to charge the phone as it was not critically low.

Referring to FIG. 5, an example standardized reporting protocol 500 isillustrated. The reporting protocol 500 can include a boot protocolwhere all battery reporting devices that desire to work with hostsshould use the boot protocol mode. A device could use both the bootprotocol and a report protocol to work with all hosts, if desired. At510, the protocol may include one or more identifiers 510 as thefollowing table defines a Class, Subclass and the Protocol code that adevice reports in the specific battery reporting HID interfacedescriptor (note this is specific for USB but can be extended to otherbuses.: Code Type Code Value Class Code 0x03 Subclass Code 0x01 ProtocolCode 0x03

The following example represents a report descriptor format 520 for aboot mode protocol battery reporting device. It is to be appreciatedthat more or less than the example parameters shown can also beprovided. Usage Page (Generic Device Controls Page), Usage (BatteryStrength), Collection (Application),  Report Size (8),  Report Count(1),  Logical Minimum (0),  Physical Minimum (0),  Logical Maximum(255),  Usage (Constant - RESERVED)  ;  ; Charging or Discharging Report size (1)  Physical Maximum (1)  Logical Maximum (1)  Usage(**Charging/Discharging**)  ;  ; Padding for remaining 7bits.  ReportSize (7),  Usage (Constant - RESERVED)  ;  ; Battery Strength  Reportsize (8)  Logical Maximum (255)  Physical Maximum (255)  Usage(**Battery Strength**) End Collection;

At 530, one or more report formats may be employed to report batterystrength and can include schemas, XML codes, wireless XML (WML), and soforth. At 540, example information that manufacturers may desire toreport from the device to the host may include the following reportingcodes: Property Title Property Description Current Operation Is thedevice currently charging itself or Mode discharging itself. RemainingPower - What percentage of the battery is used up as percentageRemaining Power - Amount of time in mins/hours/days that the as timecurrent charge will last with current usage Battery STRING - The name ofthe company that Manufacturer Name manufactured the battery (most likelydifferent from final device manufacturer). Battery Product STRING - Thename and model number of the Name battery (should be identical toprinted model on battery). Remaining Time Indicated the min threshold ofRemaining Power - Alarm - as as percentage, below which the end userpercentage receive a notification. Remaining Time Indicated the minthreshold of Remaining Power - Alarm - as time as time, below which theend user receive a notification. Battery Serial Unique serial numberidentifying the battery. Number Battery Device Details of the chemicalcharacteristics of the Chemistry battery. This could be used by theIHV's application to predict battery charging and discharging trends.Manufacturer Date Date when the battery was manufactured of BatteryUniversal Resource For reporting status or ordering new batteries forLocator (URL) example

Referring now to FIG. 6, an example user interface 600 is illustratedfor reporting system or remote device power status in a centralizedlocation. The interface 600 shows a PDA reporting its battery strengthboth in terms of the following:

a percentage of battery charge remaining

Number of hours left to drain (at current usage level)

Charging or discharging status indicator.

Other features not shown could include a display reporting its batterystrength via a changing bar chart and a percentage value, for example.As can be appreciated substantially any type of status can be reportedin a plurality of different ways. Also, it is noted that the userinterfaces described above can be provided as a Graphical User Interface(GUI) or other type (e.g., audio or video file reporting batterystatus). For example, the interfaces can include one or more displayobjects (e.g., icon) that can include such aspects as configurableicons, buttons, sliders, input boxes, selection options, menus, tabs andso forth having multiple configurable dimensions, shapes, colors, text,data and sounds to facilitate operations with the systems or devicesdescribed herein. In addition, user inputs can be provided that includea plurality of other inputs or controls for adjusting and configuringone or more aspects described herein. This can include receiving usercommands from a mouse, keyboard, speech input, web site, browser, remoteweb service and/or other device such as a microphone, camera or videoinput to affect or modify operations of the various components describedherein.

With reference to FIG. 7, an exemplary environment 710 for implementingvarious aspects described herein includes a computer 712. The computer712 includes a processing unit 714, a system memory 716, and a systembus 718. The system bus 718 couples system components including, but notlimited to, the system memory 716 to the processing unit 714. Theprocessing unit 714 can be any of various available processors. Dualmicroprocessors and other multiprocessor architectures also can beemployed as the processing unit 714.

The system bus 718 can be any of several types of bus structure(s)including the memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, 11-bit bus, IndustrialStandard Architecture (ISA), Micro-Channel Architecture (MSA), ExtendedISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Universal Serial Bus (USB),Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), and Small Computer SystemsInterface (SCSI).

The system memory 716 includes volatile memory 720 and nonvolatilememory 722. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computer712, such as during start-up, is stored in nonvolatile memory 722. Byway of illustration, and not limitation, nonvolatile memory 722 caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable ROM (EEPROM), or flashmemory. Volatile memory 720 includes random access memory (RAM), whichacts as external cache memory. By way of illustration and notlimitation, RAM is available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM).

Computer 712 also includes removable/non-removable,volatile/non-volatile computer storage media. FIG. 7 illustrates, forexample a disk storage 724. Disk storage 724 includes, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memorystick. In addition, disk storage 724 can include storage mediaseparately or in combination with other storage media including, but notlimited to, an optical disk drive such as a compact disk ROM device(CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RWDrive) or a digital versatile disk ROM drive (DVD-ROM). To facilitateconnection of the disk storage devices 724 to the system bus 718, aremovable or non-removable interface is typically used such as interface726.

It is to be appreciated that FIG. 7 describes software that acts as anintermediary between users and the basic computer resources described insuitable operating environment 710. Such software includes an operatingsystem 728. Operating system 728, which can be stored on disk storage724, acts to control and allocate resources of the computer system 712.System applications 730 take advantage of the management of resources byoperating system 728 through program modules 732 and program data 734stored either in system memory 716 or on disk storage 724. It is to beappreciated that various components described herein can be implementedwith various operating systems or combinations of operating systems.

A user enters commands or information into the computer 712 throughinput device(s) 736. Input devices 736 include, but are not limited to,a pointing device such as a mouse, trackball, stylus, touch pad,keyboard, microphone, joystick, game pad, satellite dish, scanner, TVtuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 714through the system bus 718 via interface port(s) 738. Interface port(s)738 include, for example, a serial port, a parallel port, a bluetoothradio, a wireless USB or UWB radio, a game port, and a universal serialbus (USB—both wired and wireless). Output device(s) 740 use some of thesame type of ports as input device(s) 736. Thus, for example, a USB portmay be used to provide input to computer 712, and to output informationfrom computer 712 to an output device 740. Output adapter 742 isprovided to illustrate that there are some output devices 740 likemonitors, speakers, and printers, among other output devices 740, thatrequire special adapters. The output adapters 742 include, by way ofillustration and not limitation, video and sound cards that provide ameans of connection between the output device 740 and the system bus718. It should be noted that other devices and/or systems of devicesprovide both input and output capabilities such as remote computer(s)744.

Computer 712 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)744. The remote computer(s) 744 can be a personal computer, a server, arouter, a network PC, a workstation, a microprocessor based appliance, apeer device or other common network node and the like, and typicallyincludes many or all of the elements described relative to computer 712.For purposes of brevity, only a memory storage device 746 is illustratedwith remote computer(s) 744. Remote computer(s) 744 is logicallyconnected to computer 712 through a network interface 748 and thenphysically connected via communication connection 750. Network interface748 encompasses communication networks such as local-area networks (LAN)and wide-area networks (WAN). LAN technologies include Fiber DistributedData Interface (FDDI), Copper Distributed Data Interface (CDDI),Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WANtechnologies include, but are not limited to, point-to-point links,circuit switching networks like Integrated Services Digital Networks(ISDN) and variations thereon, packet switching networks, and DigitalSubscriber Lines (DSL).

Communication connection(s) 750 refers to the hardware/software employedto connect the network interface 748 to the bus 718. While communicationconnection 750 is shown for illustrative clarity inside computer 712, itcan also be external to computer 712. The hardware/software necessaryfor connection to the network interface 748 includes, for exemplarypurposes only, internal and external technologies such as, modemsincluding regular telephone grade modems, cable modems and DSL modems,ISDN adapters, and Ethernet cards.

FIG. 8 is a schematic block diagram of a sample-computing environment800 that can be employed. The system 800 includes one or more client(s)810. The client(s) 810 can be hardware and/or software (e.g., threads,processes, computing devices). The system 800 also includes one or moreserver(s) 830. The server(s) 830 can also be hardware and/or software(e.g., threads, processes, computing devices). The servers 830 can housethreads to perform transformations by employing the components describedherein, for example. One possible communication between a client 810 anda server 830 may be in the form of a data packet adapted to betransmitted between two or more computer processes. The system 800includes a communication framework 850 that can be employed tofacilitate communications between the client(s) 810 and the server(s)830. The client(s) 810 are operably connected to one or more client datastore(s) 860 that can be employed to store information local to theclient(s) 810. Similarly, the server(s) 830 are operably connected toone or more server data store(s) 840 that can be employed to storeinformation local to the servers 830.

What has been described above includes various exemplary aspects. It is,of course, not possible to describe every conceivable combination ofcomponents or methodologies for purposes of describing these aspects,but one of ordinary skill in the art may recognize that many furthercombinations and permutations are possible. Accordingly, the aspectsdescribed herein are intended to embrace all such alterations,modifications and variations that fall within the spirit and scope ofthe appended claims. Furthermore, to the extent that the term “includes”is used in either the detailed description or the claims, such term isintended to be inclusive in a manner similar to the term “comprising” as“comprising” is interpreted when employed as a transitional word in aclaim.

1. An automated power reporting system, comprising: a plurality of devices that report power status information over a bus or network, the plurality of devices comprise at least one of a driver, processor network card, system controller, cell phone, and camera; and a protocol component that employs a generalized protocol to process the power status information over the bus or network in order to facilitate power management operations for the plurality of devices, the generalized protocol is scalable to enable differing vendors of the plurality of devices to control power management in a proprietary manner and still enable centralized reporting of device power status of the plurality of devices according to prescribed interfaces of the protocol component.
 2. The system of claim 1, the network includes at least one personal computer bus, or at least one wireless connection, or at least one wired network connection.
 3. The system of claim 1, the protocol component enables current battery status to be automatically sent by the device or programmatically retrieved from the devices.
 4. The system of claim 3, further comprising a threshold component that triggers a notification when the battery status crosses a predetermined threshold or set of thresholds.
 5. The system of claim 4, the predetermined thresholds are adjustable per user.
 6. The system of claim 1, the protocol component enables multiple sources to report battery information to at least one host.
 7. The system of claim 1, further comprising an interface that enables one or more components to be added for specific battery types or devices.
 8. The system of claim 1, further comprising a component to facilitate battery life profiling that provides a representative battery status to time left mappings.
 9. The system of claim 1, further comprising a user interface that displays battery status of each device associated with a system.
 10. The system of claim 1, further comprising a component to notify a user when to charge or replace a battery based at least in part on the user's schedule and usage history.
 11. The system of claim 1, the protocol component supports a HID boot protocol mode.
 12. The system of claim 1, the protocol component includes at least one identifier code for battery reporting.
 13. The system of claim 1, the protocol component includes at least one report descriptor for reporting devices.
 14. The system of claim 13, the report descriptor includes a usage page, a usage parameter, a collection parameter, a charging or discharging parameter, or a battery strength indication.
 15. A computer readable medium having computer readable instructions stored thereon for implementing the components of claim
 1. 16. A method for reporting device power status, comprising: defining a generic reporting protocol for devices to report power status to a host, the generic protocol is scalable to enable differing vendors of the devices to control power management in a proprietary manner and still enable centralized reporting of device power status of the devices according to prescribed interfaces of the generic protocol; communicating the power status from the devices to the host over local or remote networks; and displaying power status of the devices at the host according to the reporting protocol, the reporting protocol is a human interface device (HID) protocol.
 17. The method of claim 16, further comprising creating a generalized operating system service to monitor power messages and report power status from the devices.
 18. (canceled)
 19. The method of claim 16, further comprising creating at least one device driver application programming interface extension to enable device power reporting.
 20. A system to facilitate automated device power status reporting, comprising: means for defining a generic reporting protocol for a plurality of devices to report power status to a host, the generic protocol is scalable to enable differing vendors of the plurality of devices to control power management in a proprietary manner and still enable centralized reporting of device power status of the plurality of devices according to prescribed interfaces of the generic protocol means for communicating power status information from the plurality of devices to at least one host computer; means for displaying the power status information at the host computer; and means for triggering notification events to users based at least in part on the power status information; wherein the plurality of devices comprise at least one of a driver, processor, network card, system controller, cell phone, and camera. 